Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# 7.x: Tuples #63

Closed
wants to merge 12 commits into from
Closed

C# 7.x: Tuples #63

wants to merge 12 commits into from

Conversation

RexJaeschke
Copy link
Contributor

This (Draft) PR is not quite complete.

@RexJaeschke
Copy link
Contributor Author

This PR adds the new section, "§deconstruction-expressions-new-clause Deconstruction expressions", which defines the grammar rule tuple_deconstruction_expression. However, that rule is not currently reachable, so we need to figure out where to insert it in the expressions rule hierarchy.

@Nigel-Ecma
Copy link
Contributor

This PR adds the new section, "§deconstruction-expressions-new-clause Deconstruction expressions", which defines the grammar rule tuple_deconstruction_expression. However, that rule is not currently reachable, so we need to figure out where to insert it in the expressions rule hierarchy.

Good point! There is grammar missing, and the grammar that does exist is left recursive…

First let’s complete the grammar, but not make it reachable. Currently from the text a tuple_deconstruction_expression can only appear as part of a tuple deconstruction statement, so the grammar would be something like:

tuple_deconstruction_statement
    : tuple_deconstruction_expression '=' expression
    ;
    
tuple_deconstruction_expression
    : '(' destination (',' destination)* ')'
    ;
    
destination
    : type? identifier
    ;

Left recursion is gone, and tuple_deconstruction_expression is reachable from * tuple_deconstruction_statement*, but the latter is not reachable yet.

Now how to make it reachable, i.e. where does it fit into the grammar? The text suggests it is a statement_expression however all the subclauses of that are expressions which can occur elsewhere, a tuple_deconstruction_statement can only be at the statement level. (Note that while a * tuple_deconstruction_statement* may only assign to existing variables unlike assignment it cannot be a sub-expression of another expression.)

The other obvious choices are: a subclause of declaration_statement – as one or more variables may be declared; a subclause of embedded_statement – on par with other statement kinds and in the hierarchy which contains assignment; or a subclause of statement itself.

Subjectively I’d lean to one on the last three and away from statement_expression, YMMV and I haven't checked where Roslyn puts it as someone will know!

No space is allowed between the § and the name.
;
```

Element values are copied from the source tuple to the destination(s). Each element's position is inferred from the destination position within *destination_list*. If no variable called “_” is in scope, a *destination* with *identifier* `_` indicates a discard (§discards-new-clause), and the corresponding element is discarded rather than being copied. (Discards are discussed further below.) The destination list shall account for every element in the tuple.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reference to discards-new-clause is causing the one build warning.

@BillWagner
Copy link
Member

BillWagner commented Oct 5, 2022

See #64 for remaining questions

@@ -101,6 +127,20 @@ There are no predefined implicit conversions to the `char` type, so values of th

An implicit enumeration conversion permits a *constant_expression* ([§11.20](expressions.md#1120-constant-expressions)) with any integer type and the value zero to be converted to any *enum_type* and to any *nullable_value_type* whose underlying type is an *enum_type*. In the latter case the conversion is evaluated by converting to the underlying *enum_type* and wrapping the result ([§8.3.11](types.md#8311-nullable-value-types)).

### §tuple-conversions-new-clause Tuple conversions

Tuple types and expressions support a variety of conversions by "lifting" conversions of the elements into overall *tuple conversion*. For the classification purpose, all element conversions are considered recursively. For example, to have an implicit conversion, all element expressions/types shall have implicit conversions to the corresponding element types.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Define "corresponding".

@@ -1402,6 +1407,58 @@ Then:

*end example*

### §tuple-literal-expressions-new-clause Tuple literal expressions

A tuple literal consists of two or more tuple literal elements, each of which is optionally named.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

>
> *end example*

A tuple cannot be created with the `new` operator. However, the `new` operator can be used to create and initialize an array of tuple or a nullable tuple.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new Tuple<String, String>("a", "b") is legal. The rule is that a tuple type syntax cannot be used with the new operator.

@BillWagner
Copy link
Member

Closed in favor of #664

@BillWagner BillWagner closed this Apr 20, 2023
@RexJaeschke RexJaeschke deleted the Rex-v7-tuples branch June 9, 2023 11:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants